REMARKS 

In the Official Action mailed on 15 December 2005, the Examiner 
reviewed claims 1-11, 13-29, 31-47, and 49-54. Claims 1, 4, 5, 8, 9, 13, 15, 16, 
18, 19, 22, 23, 26, 27, 31, 33, 34, 36, 37, 40, 41, 44, 45, 49, 51, 52, and 54 were 
rejected under 35 U.S.C. §1 03(a) as being unpatentable over Bruce Schneier 
{Applied Cryptography 2 nd Edition, Oct. 1995, John Wiley & Sons Pub. pages 43- 
57, hereinafter "Schneier") in view of Medvinski et al {Public Key Utilizing 
Tickets for Application Servers, hereinafter "Medvinski") and Kohl et al (The 
Kerberos Network Authentication Service, Network Working Group Request For 
Comments (RFC) 1510, Sept. 1993, hereinafter "Kohl"). Claims 14, 17, 32, 35, 
50, and 53 were rejected as being unpatentable over Schneier in view of 
Medvinski and Official Notice (hereinafter "ON"). Claims 2, 3, 6, 7, 10, 1 1, 20, 
21, 24, 25, 28, 29, 38, 39, 42, 43, 46, and 47 were rejected under 35 U.S.C. 103(a) 
as being unpatentable over Schneier in view of Medvinski and Sirbu et al (Public 
Key Based Ticket Granting service in Kerberos, hereinafter "Sirbu") and ON. 

Rejections under 35 U.S.C. §1 03(a) 

Independent claims 1,19, and 37 were rejected under 35 U.S.C. §103 (a) as 
being unpatentable over Schneier in view of Medvinski and Kohl. 

Applicant respectfully points out that both Medvinski and Kohl teach 
away from the present invention. 

Kohl describes the Kerberos network authentication system, which 
provides a means of verifying the identities of principals on an open network. 
Kerberos allows a client to obtain a "ticket" from a key distribution center (KDC) 
which enables the client to (a) authenticate itself to a server and (b) initiate a 
secure session with the server. Note that Kerberos uses a long-term secret key 
(with "long lifetime") which is shared between the KDC and the server to seal the 
ticket (see Kohl, section 1.3, definitions for "secret key" and "ticket"). 
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Before a client can obtain a ticket for a server, the client and server must 
authenticate themselves with the KDC. PKINIT extends Kerberos so that clients 
and servers can use public key cryptography to authenticate themselves with the 
KDC. But, after authentication, a "client can proceed in a normal fashion, using 
the conventional Kerberos ticket" (see Medvinski, last paragraph of section 4). 
Furthermore, Medvinski describes "how, without any modification, the PKINIT 
specification may be used to implement the ideas introduced in PKDA" (see 
- Medvinski, Abstract). In other words, Medvinski uses a long-term secret key to 
generate a ticket because PKINIT uses the conventional Kerberos ticket which 
uses a long-term secret key. 

In contrast, the present invention is specifically directed towards 
generating and storing a temporary secret key with a limited lifespan at the 
KDC. This temporary secret key can be subsequently used to facilitate 
communications between a client and the server. Furthermore, the temporary 
secret key becomes invalid after a specified time interval (the lifespan), and 
therefore have to be regenerated either periodically, or upon request from the 
KDC(see page 11, lines 10-14). 

Examiner argues that Kohl explicitly teaches that fact that a temporary 
secret key that becomes invalid after a specified time in Kohl, Section 3.1.5, final 
paragraph and Section 3.3.3 final paragraph. Application respectfully points out 
that in these Sections of Kohl, the referred "expiration times" are associated with 
either a "session key" or a "sub-session key", but not a secrete key (see Kohl, 
section 1.3, definitions for "session key", "sub-session key", and "secret key"). 

Note that the session key is different from the secret key. First of all, the 
secret key is shared by a principal and the KDC, and is stored at KDC. In 
contrast, the session key is generated at the time that two principals (e.g., a client 
and a server) need to establish communications, and then shared by the two 
principals. Secondly, the lifetime or lifespan of the session key is associated with 
a communication session, while the lifetime of the secrete key is not associated 
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with a communication session. Thirdly, the temporary secret key is used to create 
a ticket by "encrypting an identifier for the client and the session key with the 
temporary secret key," in the instant application, while the session key is used for 
direct communication between the client and the server. Hence, Kohl does not 
reveal a temporary secret key that becomes invalid after a specified time. 

Using a temporary secret key which is stored at the KDC is advantageous 
because it reduces the vulnerability at the KDC. Note that vulnerability is reduced 
because the temporary key will become invalid after a specified time period (see 
page 9, lines 24-26), and a new temporary secret key is subsequently generated to 
replaced the expired temporary secret key (see page 1 1, lines 10-14). 
Furthermore, managing temporary secret keys is not obvious because it involves 
the complex operations shown in FIG. 2. 

Accordingly, Applicant has amended independent claims 1, 19, and 37 to 
clarify that invalidating the temporary secret key after a specified time, and 
replacing the expired temporary secret key with a new temporary secret key 
reduces the vulnerability of the KDC. These amendments find support on page 9, 
lines 24-26, and page 11, lines 10-14. 

Hence, Applicant respectfully submits that independent claims 1,19, 
and 37 as presently amended are in condition for allowance. Applicant also 
submits that claims 2-1 1 and 13-18, which depend upon claim 1, claims 21-29 
and 31-36, which depend upon claim 19, and claims 38-47 and 49-54, which 
depend upon claim 37, are for the same reasons in condition for allowance and for 
reasons of the unique combinations recited in such claims. 
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A 



CONCLUSION 



It is submitted that the present application is presently in form for 
allowance. Such action is respectfully requested. 



Edward J. Grundler 

PARK, VAUGHAN & FLEMING LLP 

2820 Fifth Street 

Davis, CA 95616 

Tel: (530) 759-1663 

FAX: (530) 759-1665 

Email: edward@parklegal.com 



Respectfully submitted, 



By 




Ed Ward J. Grundler 
Registration No. 47,615 



Date: 15 March 2006 
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